Test Drive of TimeShift 2000
by
Shawn M. Gordon
President
S.M.Gordon & Associates

What it can do?

As the year 2000 get’s closer, we are seeing more and more ways to test and solve our problems. This month we look at TimeShift 2000. TimeShift provides two main functions, one is in depth analysis of dates within your database, which includes things like finding your date fields, tallying the types of dates it find as well as “special” or “invalid” dates, and the other is to “age” the dates in the database by a value such as days or years. What this does is allow you to actually test your changes, whether they be bridging, or date expansion, with actual data in the date range required to verify your tests.

This aging process is critical to make sure that you are going to have your programs respond correctly, even doing virtual dates will only help partially because your data will still be in it’s original form. There are three basic problems that need to be addressed in terms of Y2K compliance, they are;

1) Date range retrieval that cross centuries
2) Date math that crosses centuries
3) Sorting files or sorted keys, on dates that don’t include the century

So as you can see, it’s important to also have data that allows you to properly address these issues, and that’s what TimeShift will do. Not to mention finding many of the invalid dates that you might have in your database.

How does it work?

What TimeShift does is to use some fairly clever JCl to try to find all the databases in the logon account of it’s collection job stream. It will then generate a schema file using either ADAGER, DBGENRAL, or QUERY, in that order, of the database. It then scans through the schema finding all the fields that contain any of the strings contained in the TSPARM file, which by default ships with the following values;

DATE
DTE
YMD
MDY
YEAR
YY

This automatic scanning is very convenient, and reduces the work on your part. This step also produces a report giving you some statistics about the dates and how they are spread in your system, see figure 1 for an example.

You now have a file that will be downloaded to the PC and used to do granular configuration of how you want to age each date field on an individual basis, see figure 2 and figure 3 for an example of how the program looks. After you make whatever changes you are interested in, deleting, adding, specifying aging parameters, you click on the button to put it back on the HP.

After the data is on the HP, you stream another job that reads this driver file and affects the changes.

Features

The analysis reports that are created during the load phase will be helpful in determining how you want to configure the aging process, and while they give you very nice, concise summary information, there doesn’t seem to be a way to get any detail information for any “invalid”
dates the software might find.

Putting the actual configuration program on the PC certainly makes it nicer to go through and quickly switch between databases, and configure each individual item. Since you are in a grid, you can easily add and delete items from the list of prequalified items. By pre-qualifying the data information there is less burden
on you to find everything, and makes what could be a very tedious task a lot easier.

Installation and Documentation

The installation on the HP side is very clean, and only requires a single pass on the tape. On the PC side, there is an installation program which put’s the software onto your computer, but it doesn’t create a program group, or give you an option of placing the icon on the desktop. The instructions explain how to do it, but it’s a bit tedious, and the icon for the program didn’t work either. All of which is trivial, but should be cleaned up.

The TestDrive

I tried a simple example of a single database, that had a single data set with a single date field, and I tried an extreme example with a half dozen databases with a variety of date fields. As mentioned earlier, TimeShift tries to use Adager, DBGeneral or QUERY to create an item search list to find potential date item
fields. I have Adager on my system, so it tried to use that, but in my extreme example I had databases with b-trees on them, which Adager currently can’t handle. This caused Adager to gracefully exit with a message about the b-trees incompatibility, and the collection job to blow off. I let the company know, and I think they are going to go to a pure QUERY collection now. On a side note, Adager will be able to handle b-trees properly by the time you read this.

I decided to finish my tests on my simple example, whose date was stored in an X6 in YYMMDD format. After TimeShift collected the data, and generated the report in Figure 1, I activated the PC program and brought the config file down as seen in Figure 2. I then configured an offset of 4 years, Figure 3, and sent the file back up to the PC.

As a side note, TimeShift makes use of the OLE methods that have been exposed in the Reflection terminal emulator, to upload and download the config file, so you can only have one copy of Reflection running, and it needs to be logged into where the file is located.

After the file was uploaded I launched the aging job, which processed my data in a couple of seconds. I then ran my interface program to see what the data looked like, see figure 4 for an example of my aged dates after running a data set through TimeShift. As you can see, the dates all properly ended up in the year 2002. So I was able to successfully examine, and shift my database in time, showing that TimeShift does what it claims to do.

Conclusions

Data aging is a critical part of thoroughly testing your applications, and something that everyone should look at. G.R.Helm has done a nice job with TimeShift 2000, and goes beyond straight data aging by providing nice detailed analysis of your data. There are a number of limitations in the current
release that might make the software less than ideal for some situations. You can only age dates that are in a database, no MPE or KSAM file support, and you can only age dates that are actual image fields, in other words you can’t do byte offsets into buffers to age an embedded date. If you don’t have either of those two requirements, and you are serious about your Y2K testing, then a product like TimeShift is something you should definitely give consideration to.

Road Report

TimeShift 2000 version A.00.00 – PC software V2.2
G.R.Helm, Inc.
4993 Golden Foothill Pkwy., Ste 1
El Dorado Hills, CA 95762
Phone 916-933-9669
FAX 916-933-9696
email: sales@grhelm.com
http://www.grhelm.com

TimeShift includes the 3000 based transformation software and the Windows based software. It supports a config per account, and as many databases as exist. Demo version will only update 1/3 of your data or 1000 records, whichever is less.

TimeShift for the HP 3000 runs on all HP 3000 Series 900s, MPE/iX 4.0 or later. The software also requires that you be using the Reflection terminal emulator software from WRQ. The software is tier based ranging from $990 to $8,000. 25% discount on multiple CPUs. Support is 15% of the purchase price per year and includes phone in, electronic support and new releases of the software. All prices are in US dollars.

Figure 1

TIMELOOK                         Shawn Gordon                      PAGE     1
VER  A.00.00                 TIME LOOK ANALYSIS              06/23/1998 14:27

  DATA                       SET                       ITEM     DATE    DATA
  BASE        DATA SET       TYPE      DATA FIELD     DEFINED  FORMAT  OFFSET
--------  ----------------  ------  ----------------  -------  ------  ------
TRACE;    RUN-STAT-D        DETAIL  RUN-DATE             X6    YMD         01

  YMD DATE RANGE--
    LOW:   980417               HIGH:    980623

  DISTRIBUTION OF YEARS--
            0 :01          0 :21          0 :41          0 :61          0 :81
            0 :02          0 :22          0 :42          0 :62          0 :82
            0 :03          0 :23          0 :43          0 :63          0 :83
            0 :04          0 :24          0 :44          0 :64          0 :84
            0 :05          0 :25          0 :45          0 :65          0 :85
            0 :06          0 :26          0 :46          0 :66          0 :86
            0 :07          0 :27          0 :47          0 :67          0 :87
            0 :08          0 :28          0 :48          0 :68          0 :88
            0 :09          0 :29          0 :49          0 :69          0 :89
            0 :10          0 :30          0 :50          0 :70          0 :90
            0 :11          0 :31          0 :51          0 :71          0 :91
            0 :12          0 :32          0 :52          0 :72          0 :92
            0 :13          0 :33          0 :53          0 :73          0 :93
            0 :14          0 :34          0 :54          0 :74          0 :94
            0 :15          0 :35          0 :55          0 :75          0 :95
            0 :16          0 :36          0 :56          0 :76          0 :96
            0 :17          0 :37          0 :57          0 :77          0 :97
            0 :18          0 :38          0 :58          0 :78         97 :98
            0 :19          0 :39          0 :59          0 :79          0 :99
            0 :20          0 :40          0 :60          0 :80          0 :00

 BLANK:         0    ZEROS:         0    NINES:         0  UNKNOWN:         1
 TOTAL:           98


Figure 4
J O B T R A K / 3 0 0 0             DAY RUN                   06/24/98   C.03.01


Job Name                     Run Date   Time End   Exec Min   Streaming User   <-#> 
FULLBACK.JCL.SYS             06/04/02    6:30 AM        510   MASTEROP,MANAGER. 
BACKJOBS.JCL.SYS             06/04/02    6:30 AM          0   MASTEROP,MANAGER. 


TOTAL TIME:       510
TOTAL JOBS:         2


(N)ext, (P)rev, YYMMDD (020604) or < to continue